Motivation

Why do you insist on using a notation which is a nightmare for typist and compositor and impossible to implement with punching and printing equipment currently available?
<#30#><#30#>filll -- R.~A.~Brooker, 1963 [#Iverson##1###]

Since its introduction in the early sixties, <#860#>APL<#860#> has been known and even become famous not so much for the power and elegance of its concepts butto a much greater extentfor the ``strange'' symbols it uses. A discussion about the usefulness and difficulties of <#861#>APL<#861#> has remained academic for large parts of the computer science community. Many programmers never managed to get their dumb <#862#>ASCII<#862#><#36#><#36#>--terminals to produce the non-<#863#>ASCII<#863#><#38#><#38#> symbols required by the language.

With the advent of bit-mapped displays, down-loadable fonts and the spread of graphical interfaces such as the X Window System the situation has changed. Specialized hardware is no longer a prerequisite for <#864#>APL<#864#> programming. Although it often requires some effort of customization and configuration, it is possible nowadays to turn existing hardware into an <#865#>APL<#865#> environment.

Troubles show up as soon as you start publishing results produced in your <#866#>APL<#866#> environment. (Just have a look at some books on <#867#>APL<#867#>, where the <#868#>APL<#868#> passages had to be pasted in!) Since many text-processing and desktop-publishing systems still lack <#869#>APL<#869#> support, it remains difficult to achieve high printing quality in publications composed of text and <#870#>APL<#870#> code. Several extensions to existing text processors have been implemented (cf. [#Hohti##1###]). However, most of them support either only the symbols of one <#871#>APL<#871#> dialect or only one machine or operating system platform. [#Hohti##1###] already demonstrated the usefulness of TEX for <#872#>APL<#872#> typesetting. The authors produced a METAFONT description for <#873#>APL<#873#> primitive symbols and a set of TEX<#43#><#43#> macros to support Digital's <#874#>APL<#874#> interpreter for the VAX-11 series.

In this paper we present our solution to the problem: An <#875#>APL<#875#> publishing system consisting of an <#876#>APL<#876#> front end and a L^ATEX document style option. The <#877#>APL<#877#> front end automatically converts <#878#>APL<#878#> material into L^ATEX code which you can 1 into any standard L^ATEX document. The L^ATEX document style option <#879#>apl.sty<#879#> provides macros defining all <#880#>APL<#880#> characters as combinations of standard L^ATEX symbols, thus relieving us from the burden of designing new fonts and the user from the task of incorporating them into the L^ATEX system. As additional benefit, size and type style of the <#881#>APL<#881#> symbols can be changed by the familiar L^ATEX commands (e.g. 2, 3).

Compared with the approach of Hohti and Kanerva mentioned above, our solution offers the following advantages:

<#748#>

• Several <#882#>APL<#882#> dialects are supported (currently <#883#>APL<#883#>2, Dyalog <#884#>APL<#884#>, I--<#885#>APL<#885#>, Sharp <#886#>APL<#886#>, and <#887#>APL<#887#>.68000).
• No additional fonts are required.
• <#888#>APL<#888#> symbols for all L^ATEX sizes and type styles are available.
• We provide support for automatic typesetting of <#889#>APL<#889#> objects.

There are some disadvantages, however; they are higher TEX interpretation overhead and higher TEX memory usage.